
200 C
HAPTER 9
Using alternative protocols
RabbitMQ Web STOMP servers as standalone clusters or servers that bridge to your
main servers using tools like the Shovel and Federation plugins to mitigate the impact
of malicious or abusive clients. For more information on Web STOMP, visit the plugin
page at www.rabbitmq.com/web-stomp.html.
The STOMP protocol is a human-readable, text-based streaming protocol designed
to be simple and easy to implement. Although binary protocols such as AMQP and
MQTT may be more efficient on the wire, using less data to transfer the same message,
the STOMP protocol has some advantages, especially when using the STOMP plugin
with RabbitMQ. The queue creation and binding behaviors require less code on your
end, but they also come at a cost. The proxied AMQP connections created by the
STOMP plugin that are used to communicate the translated STOMP data with
RabbitMQ have overhead that direct AMQP connections do not have.
As with the various options that are available to you in publishing and consuming
AMQP messages, I highly recommend that you benchmark the use of STOMP with
RabbitMQ prior to using it in production. Each protocol has its advantages and disad-
vantages, and in some cases, neither is ideal.
In the next section, we’ll cover statelessd, a web application used for high-
performance, stateless publishing into RabbitMQ. It was created for scenarios where
both the AMQP and STOMP protocols carry too much protocol overhead for single-
transaction, fire-and-forget publishing.
9.3 Stateless publishing via HTTP
In some scenarios, AMQP, MQTT, STOMP, and other stateful protocols are expensive
for environments with high message velocities that can’t maintain long-running con-
nections to RabbitMQ. Because these protocols have a bit of overhead related to
connecting prior to being able to take message-related actions, they can be less than
ideal, from a performance perspective, for short-lived connections. It was this realiza-
tion that led to the development of statelessd, an HTTP-to-AMQP publishing proxy
that enables high-performance, fire-and-forget message publishing for client applica-
tions without requiring the overhead of connection state management.
9.3.1 How statelessd came to be
Sometime in mid-2008 we started to build out our asynchronous messaging architec-
ture at MeetMe.com (then myYearbook.com) as a way to decouple database writes
from our PHP-based web application. Initially we built this architecture using Apache
ActiveMQ, a Java-based message broker service with support for the STOMP protocol.
As foundationally important as memcached was to the success of our database-read
scaling, messaging, STOMP, and ActiveMQ allowed us to create consumer applica-
tions that fundamentally changed how we thought about database writes, constraining
workloads, and scaling out computationally expensive workloads.
As our traffic grew, we encountered scaling issues with ActiveMQ and started to
evaluate other brokers. At the time, RabbitMQ showed a lot of promise and supported